• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    mobile device and magnetic sensor key pairing for multifactor security are systems and methods provided for determining a first proximity situation of a first mobile device to a vehicle and for determining a second proximity situation of a second device mobile relative to the vehicle. additionally, an accessibility of one or more functions of the vehicle can be configured based, at least in part, on the first proximity situation and the second proximity situation. in one example, a policy associated with one or more of the first mobile device and the second mobile device can be identified, where reachability is further configured based on the policy.
    公开号:BR112015004588B1
    申请号:R112015004588-0
    申请日:2013-09-16
    公开日:2021-06-01
    发明作者:Steven Birkel；Rita Wouhaybi；Tobias Kohlenberg；Stanley Mo；Joni D. Stutman
    申请人:Intel Corporation；
    IPC主号:
    专利说明:

    FIELD OF THE INVENTION
    [0001] The modalities generally refer to security systems. More particularly, modalities refer to the use of multiple factors to control vehicle access.
    [0002] Vehicle entry systems may include proximity-based keyless remote controls (eg magnetic sensor keys) that can be used to access and/or start the vehicle. While these solutions may be suitable under certain circumstances, there is considerable room for improvement. For example, unauthorized access and/or operation of the vehicle can be achieved simply by gaining possession of the key by magnetic sensor, which can be the single-user authentication factor in relation to the vehicle. Furthermore, if the auto switch key is lost or stolen, a new auto switch key can be ordered, which can be considerable cost, delay and inconvenience to the owner. Even though certain smart phone apps may allow remote control of vehicles, these apps may also be limited to using login credentials to establish the phone as the only user authentication factor against the vehicle, where the login credentials can be easily compromised. Furthermore, smart phone-based solutions may involve the use of an intermediary (eg service provider) between the phone and the vehicle. BRIEF DESCRIPTION OF THE DRAWINGS
    [0003] The various advantages of the embodiments of the present invention will become apparent to a person skilled in the art by reading the descriptive report and the appended claims by reference to the following drawings, in which:
    [0004] Figure 1 is a block diagram of an example of an authentication environment according to a modality;
    [0005] Figures 2A and 2B are block diagrams of examples of factor substitution scenarios according to the modalities;
    [0006] Figure 3 is a block diagram of an example of a logical architecture according to a modality;
    [0007] Figure 4 is a block diagram of an example of a set of user profiles according to a modality;
    [0008] Figure 5 is a flowchart of an example of a method of managing a multifactor authentication environment according to a modality;
    [0009] Figure 6 is a block diagram of an example of a processor according to a modality; and
    [0010] Figure 7 is a block diagram of an example of a system according to a modality. DETAILED WRITING
    [0011] Turning now to Figure 1, an authentication environment 10 is shown in which access to a vehicle 14 and control over it is managed with respect to a plurality of mobile devices 16, 18 that are paired with the vehicle 14. In the illustrated example, a first mobile device 16 is a magnetic sensor key (eg, wireless hardware security token) and a second mobile device 18 is a smart phone. Mobile devices 16, 18 may also include other types of devices such as smart tablet computers, personal digital assistants (PDAs), media players, imaging devices, and so on, where a user 12 can carry the mobile devices 16 , 18 with it as it approaches or interacts with the vehicle 14. As will be discussed in more detail, the presence of mobile devices 16, 18 may be required in order to authenticate user 12, where authentication succeeds. may result in certain functions of vehicle 14 being made available to user 12. For example, the presence of both mobile devices 16, 18 may be required before user 12 is allowed to access vehicle 14 (e.g. unlocking the door and/or trunk), starting the vehicle 14 (eg ignition function), customizing various settings (eg user adjustment function), driving the vehicle 14 (eg lo, vehicle operation function), pairing devices with the vehicle 14 (for example, device pairing functions) and so on. In this way, the illustrated environment 10 represents a "multi-factor" authentication environment in which the security of the vehicle 14 is a function of the proximity status of various mobile devices 16, 18.
    [0012] As will be discussed in more detail, user profiles and/or policies can also be used to make certain functions, such as vehicle access and device pairing, available to user 12 even if only one of the mobile devices 16, 18 is present. Additionally, even though two mobile devices are shown, more than two mobile devices can also be used by a given user to access vehicle functions. For example, user 12 can pair a smart phone, smart tablet computer, and media player with vehicle 14 and designate the smart phone as the primary device (eg, "master"), in which the primary device can be used to pair other devices with the vehicle 14.
    [0013] For example, Figure 2A demonstrates that a policy can be implemented where user 12 is allowed to enter vehicle 14 if first mobile device 16 is present but second mobile device 18 is not. Such a case can occur if the second mobile device 18 is lost or stolen or user 12 merely forgets to take the second mobile device 18. The policy, which can be deployed as a user profile that corresponds to user 12 or as a global policy (eg default profile) applicable to all users or user groups, may also allow a replacement device 20 (eg smart phone) to be paired with vehicle 14 as long as θ user 12 satisfies, with successful, a login restriction (for example, entering a predefined passcode) associated with the user's user profile 12 and complete a pairing process. .
    [0014] Similarly, Figure 2B demonstrates that the user profile can allow user 12 to enter vehicle 14 if second mobile device 18 is present, but first mobile device 16 is not present. Such a case can occur if the first mobile device 16 is lost or stolen or the user 12 merely forgets to take the first mobile device 16. The user profile may also allow a replacement device 22 (e.g., key per sensor magnetic), is paired with vehicle 14, provided user 12 successfully satisfies the login restriction associated with user profile 12, and completes the pairing process. In this way, the use of a multifactor authentication scheme can enable new factors to be paired with vehicle 14 with considerably less cost, delay and inconvenience for user 12, while maintaining a relatively high level of security relative to vehicle 14.
    [0015] Turning now to Figure 3, a logical architecture 24 (24a to 24d) is shown, in which the logical architecture 24 can be generally incorporated into a vehicle such as vehicle 14 (Figures 1, 2A and 2B) as hardware, software, firmware or any combination thereof. In the illustrated example, a first 24a factor module uses a proximity sensor (not shown) to determine a first proximity situation of the first mobile device 16 with respect to the vehicle. Similarly, a second factor 24b module may use a proximity sensor to determine a second proximity situation of the second mobile device 18 to the vehicle. A security module 24c may have a request component 40 that receives a user request via a user interface (UI) 30 (e.g. push button, switch, etc.) of the first mobile device 16, a UI 32 (eg touchscreen, microphone, etc.) from the second mobile device 32, a UI 34 (eg door handle, push button, touchscreen, etc.) from the vehicle, etc. and configures an accessibility of one or more functions 26 (26a to 26c) of the vehicle in response to the user request based at least in part on the first proximity situation and the second proximity situation. In one example, the security module 24c identifies a policy such as one or more user profiles 28, wherein at least one of the user profiles 28 can be associated with the first mobile device 16 and/or the second mobile device 18 (and a user who corresponds to such device(s) ) . In such a case, the vehicle functions 26 can be configured based on the identified user profile.
    [0016] For example, the security module 24c may have a deny component 36 that denies user requests if the first proximity situation and the second proximity situation do not satisfy a multifactor condition of the user profile. More particularly, the multifactor condition may stipulate that both mobile devices 16, 18 (e.g. factors) are present in order that the vehicle function in question is available to the user. In such a case, if the first proximity situation indicates that the first mobile device 16 is present, but the second proximity situation indicates that the second mobile device 18 is not present, the multifactor condition would not be satisfied. Similarly, if the second proximity situation indicates that the second mobile device 18 is present, but the first proximity situation indicates that the first mobile device 16 is not present, the multifactor condition would not be satisfied.
    [0017] Other conditions such as time-based or location-based conditions can also be used. For example, if the user profile stipulates that the user in question (or all users if a global policy and/or default profile is implemented) must operate the vehicle within a certain radius of a specific location (eg street address ) and it is determined that the vehicle is outside that radius, the deny component 36 may deny vehicle operation (e.g., prevent vehicle ignition, turn off the vehicle after providing a warning to the driver, etc.). By way of another example, if the user profile stipulates that the user in question must operate the vehicle within a certain time period and it is determined that the current time is outside the specified time period, the denial component 36 can also deny vehicle operation. Furthermore, the execution of multifactor conditions can be conducted permanently. For example, if it is determined that, after a given user request has been granted, a condition leading to the granting of the request is no longer satisfied, the granting of the condition can be efficiently reversed. Thus, vehicle shutdown can be implemented in such a scenario as well. Other examples might include banning the use of radio while the vehicle is being operated to prevent distracted driver scenarios.
    [0018] The security module 24c may also have a granting component 38 that grants user requests if the first proximity situation and the second proximity situation satisfy the multifactor condition of the user profile. As will be discussed in more detail, the grant component 38 may also apply one or more restrictions such as a time restriction, location restriction, login restriction, etc., from the user profile to the vehicle role in question. With specific regard to the login restriction, the illustrated architecture 24 also includes a pairing module 24d configured to pair the first and second mobile devices 16, 18, as well as replacement devices such as device 20 (Figure 2A) and device 22 (Figure 2B), with the vehicle. Mobile devices 16, 18, and replacement devices 20 (Figure 2A), 22 (Figure 2B) can also be paired with each other. If both factors are present, the 24d pairing module can manage the pairing process normally. If, on the other hand, only one of the factors is present, the 24d pairing module can allow entry into the vehicle and then prompt the user to enter an access code (eg, personal identification number/PIN, password, etc.) before proceeding with the pairing process.
    [0019] In addition to the 24d pairing module, the passcode can be entered into one of the mobile devices 16, 18 or, in some arrangements, it may be required to be entered directly into the vehicle UI 34 in order to pair the devices 16, 18. In another modality, automatic pairing can be enabled, where a default policy and/or user profile can be used until a "master" (eg primary) device is defined. For example, a device can be considered as a master that must be present in order to pair other devices together and with the vehicle (a magnetic sensor master key, for example) . In some arrangements, pairing can only be completed when the master device is also present (for example, in order to pair a less privileged smart phone, eg operated by a child, a minor or other non-vehicle owner, and a phone intelligent). In some embodiments, a second device (eg smart phone instead of a magnetic sensor key) can be identified as a master device at the time of pairing to allow user restrictions to be entered on other secondary devices. These secondary "non-master" devices (eg, less privileged smart phone) can be prevented from having their own user restrictions changed. Secondary devices can be assigned user restrictions to be stored on the device through a number of modes: Bluetooth, wireless, NFC (near field communication), synchronization with computer or other docking cradle, etc. User restrictions can then be unmodifiable, however, except in the presence of the master device.
    [0020] Additionally, the illustrated security module 24c has a notification component 42 configured to generate a notification via the UI 30 of the first mobile device 16, the UI 32 of the second mobile device 18 and/or the UI 34 of the vehicle if the first proximity situation indicates that the first mobile device is not present or the second proximity situation indicates that the second mobile device is not present. More particularly, such notification can be useful in cases where a user is genuinely trying to operate the vehicle without one of the factors (eg the forgotten factor is missing) as well as cases where an unauthorized user is trying to operate the vehicle without one. of the factors (eg the stolen factor is present) . Notification can be sent to the next factor (eg in the case of a forgotten factor) and/or the missing factor (eg in the case of a stolen factor), depending on the circumstances.
    [0021] In the illustrated example, each of the mobile devices 16, 18 includes a policy repository 17 for storing a policy that has one or more multifactor conditions, as well as a wireless interface 19 for receiving a request from the security module 24c from the vehicle and transmit the policy to the 24c security module in response to the request. In one example, the policy is a user profile. As already noted, a given multifactor condition may indicate whether vehicle functions 26 should be accessible if first mobile device 16 or second mobile device 18 are not in proximity to the vehicle during an attempt to access vehicle functions 26. The policy may be transmitted to the security module 24c in conjunction with a pairing process and/or an attempt to access one or more functions 26 of the vehicle.
    [0022] In addition to the pairing process, the illustrated mobile devices 16, 18 also include a pairing module 21 that is configured to pair the respective device with the vehicle and/or other devices. In one example, the pairing module 21 of the first mobile device 16 receives a passcode via the UI 30 and determines whether the passcode satisfies a policy login restriction, wherein the first mobile device 16 is paired if the access code satisfy the login restriction. Similarly, the pairing module 21 of the second mobile device 18 can receive a passcode via the UI 32 and determine whether the passcode satisfies the policy login restriction, wherein the second mobile device 18 is paired if the code of access satisfy the login restriction. Alternatively, the determination as to whether the access code satisfies the login restriction can be conducted by the vehicle. Furthermore, on some occasions, a mobile device such as the first mobile device 16 (eg magnetic sensor key) may not have the capability to support the entry of login credentials. In such a case, the vehicle's UI 34 can be used or the login process can be bypassed entirely if the device is a master device.
    [0023] Figure 4 shows a set of user profiles 28 structured as a table. In the illustrated example, a plurality of users (eg "Dad", "Mother", "Sally") each have various preferences that are programmable/configurable. For example, an access code, the number of factors required to access the vehicle ("Access Factors"), the number of factors required to activate the vehicle's ignition ("Starting Factors"), the number of factors required to operating the vehicle ("Driving Factors"), location restrictions, time restrictions and so on can all be set on a user-by-user basis. Furthermore, the specified parameters can be used to determine whether to grant user requests, as well as whether to apply user-specific conditions to granted requests. It is particularly notable that different users can have different policies. For example, Mom and Dad are able to start the vehicle with only one factor present, while the profile for Sally calls for two factors to be present in order to start the vehicle, in the illustrated example. Although the illustrated set of user profiles 28 is structured as a table, the set of user profiles 28 can also use other structures known as relational database structures and/or linked lists to track, manage, control and organize the data. data represented in this document.
    [0024] Turning now to Figure 5, a method 44 of managing a multifactor authentication environment is shown. Method 44 can be deployed as a set of logical instructions and/or firmware stored on a machine- or computer-readable storage medium as random access memory (RAM), read-only memory (ROM), programmable ROM (PROM) , fast memory, etc., in configurable logic such as programmable logic arrays (PLAs), field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), in fixed-functionality logic hardware with use of circuit technology such as application-specific integrated circuit (ASIC), complementary metal oxide semiconductor (CMOS), or transistor-transistor logic (TTL) technology, or any combination thereof. For example, transistor-transistor logic (TTL) computer program code to perform the operations shown in method 44 can be written in any combination of one or more programming languages, including an object-oriented programming language such as C+ + or similar and conventional procedural programming languages such as the "C" programming language or similar programming languages. Furthermore, method 44 can be deployed as logic architecture 24 (Figure 3) which uses any of the circuit technologies mentioned above.
    [0025] The illustrated processing block 46 establishes to receive a user request via a user interface, for example, from a first mobile device, a second mobile device, a vehicle and so on. The user request can correspond to one or more vehicle functions such as a door unlocking function (eg access request), an ignition function (eg departure request), a user adjustment function (eg example, seat preferences, radio preferences), a vehicle operation function (eg put/keep transmission in), a pairing function (eg replacement device), and so on. A determination can be made at block 48 as to whether a multifactor condition is satisfied. As already noted, the multifactor condition can take into account a first situation of proximity of a first mobile device to the vehicle, a second situation of proximity of a second mobile device to the vehicle, etc., in which the condition of multifactor can satisfy if both mobile devices are present in order to make the vehicle function in question available to the user. If the multifactor condition is not satisfied, block 52 can deny the user request. Block 52 may also establish the generation of a notification via the user interface, for example, the first mobile device, the second mobile device, the vehicle or any combination thereof, in order to inform the vehicle owner of a missing, lost and/or stolen mobile device as discussed above.
    [0026] If, on the other hand, the multifactor condition is satisfied, the illustrated block 50 grants the user request and applies any relevant restrictions to the request. Both multifactor condition and restrictions can be defined on a user-by-user basis and stored in an appropriate profile, policy, etc. In one example, the restriction is a location restriction where the vehicle function is only available in certain locations. In another example, the restriction is a time restriction where the vehicle function is only available at certain times and/or for certain durations of time. In yet another example, the restriction is a login restriction where the vehicle function is only available if the user enters a predetermined access code. Login restriction can be particularly useful for pairing devices and replacement devices.
    [0027] Figure 6 illustrates a processor core 200 according to an embodiment. Processor core 200 can be the core for any type of processor, such as a microprocessor, an embedded processor, a digital signal processor (DSP), a network processor, or other device for executing code. Even though only one processor core 200 is illustrated in Figure 6, a processing element may alternatively include more than one of the processor core 200 illustrated in Figure 6. Processor core 200 may be a single run core or , for at least one embodiment, processor core 200 may have multiple executions where it may include one hardware (or "logical processor") threading context per core.
    [0028] Figure 6 also illustrates memory 270 coupled to processor 200. Memory 270 can be any of a wide variety of memories (including various layers of memory hierarchy) as are known or otherwise available to those. versed in the technique. Memory 270 may include one or more code instruction(s) 213 to be executed by processor core 200, where code 213 may implement logical architecture 24 (Figure 3), already discussed. Processor core 200 follows a program sequence of instructions indicated by code 213. Thus, processor core 200 may be part of a vehicle such as vehicle 14 (Figure 1). Processor core 200 can also be used in a mobile device such as mobile devices 16, 18 (Figure 3) to support the functionality of these devices. Each instruction can insert a front end portion 210 and be processed by one or more decoders 220. Decoder 220 can generate as its product a micro-operation as a fixed-width micro-operation in a predefined format or can generate other instructions, microinstructions or control signals that reflect the original code instruction. The illustrated front end 210 also includes register renaming logic 225 and scheduling logic 230, which generally allocate resources and queue the operation corresponding to the conversion instruction for execution.
    [0029] Processor 200 is shown including execution logic 250 which has a set of execution units 255-1 to 255-N. Some modalities may include numerous execution units dedicated to specific functions or sets of functions. Other modalities may include just an execution unit or an execution unit that can perform a particular function. The illustrated execution logic 250 performs the operations specified by the code instructions.
    [0030] Upon completion of execution of the operations specified by the code instructions, the rear-end logic 260 writes off the code 213 instructions. In one embodiment, the processor 200 allows execution out of service, but requires the write off in service. of instructions. A low logic 265 may take a variety of forms as known to those skilled in the art (e.g., reordering staging areas or the like). In this way, the processor core 200 is transformed during code execution 213, at least in terms of the output generated by the decoder, the hardware registers and tables used by the register renaming logic 225, and any registers (not shown) are modified by the execution logic 250.
    [0031] Although not illustrated in Figure 6, a processing element may include other on-board elements with processor core 200. For example, a processing element may include memory control logic along with processor core 200. The processing element may include I/O control logic and/or may include I/O control logic integrated with memory control logic. The processing element can also include one or more caches.
    [0032] Referring now to Figure 7, a block diagram of a system 1000 is shown according to an embodiment of the present invention. In one example, system 1000 is part of a vehicle such as vehicle 14, already discussed. System 1000 can also be used on a mobile device such as mobile devices 16, 18 (Figure 3) to support the functionality of these devices. Shown in Figure 7 is a multiprocessor system 1000 that includes a first processing element 1070 and a second processing element 1080. While two processing elements 1070 and 1080 are shown, it should be understood that an embodiment of system 1000 may also include just such processing element.
    [0033] System 1000 is illustrated as a point-to-point interconnection system, in which the first processing element 1070 and second processing element 1080 are coupled via a point-to-point interconnection 1050. It should be understood that any or all of the interconnects illustrated in Figure 7 can be deployed as a multipoint bus instead of a point-to-point interconnect.
    [0034] As shown in Figure 7, each of the 1070 and 1080 processing elements can consist of multi-core processors, including first and second processor cores (i.e., 1074a and 1074b processor cores and 1084a and 1084b processor cores) . Such cores 1074, 1074b, 1084a, 1084b can be configured to execute instruction code in a manner similar to that discussed above in connection with Figure 6.
    [0035] Each processing element 1070, 1080 can include at least one shared cache 1896. Shared cache 1896a, 1896b can store data (eg instructions) that are used by one or more processor components, such as cores 1074a, 1074b and 1084a, 1084b, respectively. For example, the shared cache can locally cache data stored in a 1032, 1034 memory (eg, computer readable medium, computer readable storage medium, etc.) for faster access by processor components. In one or more modalities, the shared cache can include one or more mid-level caches, such as level 2 (L2) , level 3 (L3) , level 4 (L4) or other cache levels, a last level cache (LLC ) and/or combinations thereof.
    [0036] Although shown with only two processing elements 1070, 1080, it should be understood that the scope of the present invention is not so limited. In other embodiments, one or more additional processing elements may be present on a given processor. Alternatively, one or more 1070, 1080 processing elements can be an element in addition to a processor, such as an accelerator or a field-programmable gate array. For example, the additional processing element(s) may include additional processor(s) which is a first 1070 processor, additional processor(s) which is (are) heterogeneous or asymmetric(s) to process a first 1070 processor, accelerators (such as graphics accelerators or digital signal processing units (DSP)), field programmable gate arrays or any other element of processing. There can be a variety of differences between the 1070, 1080, and 1080 processing elements in terms of a spectrum of merit metrics, including architectural, microarchitecture, thermal, power consumption, and the like characteristics. These differences can effectively manifest themselves as asymmetry and heterogeneity among the 1070, 1080 processing elements. For at least one modality, the various 1070, 1080 processing elements may reside in the same mold package.
    [0037] The first processing element 1070 may additionally include memory controller logic (MC) 1072 and point-to-point (PP) 1076 and 1078 interfaces. Similarly, the second processing element 1080 may include MC 1082 and PP interfaces 1086 and 1088. As shown in Figure 7, the MC's 1072 and 1082 couple the processors to their respective memories, that is, a memory 1032 and a memory 1034, which can be portions of main memory locally attached to the respective processors. Although MC logic 1072 and 1082 is illustrated as integrated with processing elements 1070, 1080, for alternative embodiments, MC logic may be discrete logic outside of processing elements 1070, 1080 rather than integrated thereto.
    [0038] The first processing element 1070 and the second processing element 1080 can be coupled to an I/O subsystem 1090 by means of P-P interconnects 1076, 1086 and 1084, respectively. As shown in Figure 7, the 1090 I/O subsystem includes PP 1094 and 1098 interfaces. In addition, the 1090 I/O subsystem includes a 1092 interface for coupling the 1090 I/O subsystem with a high-performance graphics engine 1038. In one embodiment, bus 1049 can be used to couple graphics engine 1038 to I/O subsystem 1090. Alternatively, a point-to-point interconnect 1039 can couple these components.
    [0039] In turn, the I/O subsystem 1090 can be coupled to a first bus 1016 through a 1096 interface. In one embodiment, the first bus 1016 can be a Peripheral Component Interconnect (PCI) bus or a bus as a PCI Express bus or other third generation I/O interconnect bus, even though the scope of the present invention is not limited.
    [0040] As shown in Figure 7, several I/O devices 1014 can be coupled to the first bus 1016, along with a bus bridge 1018 that can couple the first bus 1016 to a second bus 1020. The I/O devices 1014 can include, for example, one or more proximity sensors that can be used to determine the proximity situation of mobile devices to a vehicle. For example, proximity sensors can incorporate near-field communications technology (NFC), radio frequency identifier (RFID) technology, infrared (IR) technology, and so on. In one embodiment, the second 1020 bus may be a reduced pinout (LPC) bus. Various devices can be coupled to the second bus 1020 including, for example, a keyboard/mouse 1012, communication device(s) 1026 (which can successively be in communication with a computer network, not shown) and a storage unit data 1018 such as a disk drive or other mass storage device that may include code 1030, in one embodiment. Code 1030 may include instructions for performing embodiments of one or more of the methods described above. Thus, the illustrated code 1030 can implement the logical architecture 24 (Figure 3) and can be similar to the code 213 (Figure 6), already discussed. Furthermore, an audio I/O 1024 can be coupled to the second bus 1020.
    [0041] Note that other modalities are contemplated. For example, instead of the point-to-point architecture in Figure 7, a system can deploy a multipoint bus or other communication topology. Also, the elements of Figure 7 can alternatively be split using more or less integrated plates than shown in Figure 7.
    [0042] The technologies described in this document can therefore reduce cost by enabling general purpose devices such as smart phones, smart desks, etc., to be used for authentication purposes on a vehicle content. Additionally, delays associated with replacing lost or stolen authentication devices can be significantly reduced due to the ability to pair a wide variety of devices with the vehicle instantly. Furthermore, using customizable profiles and/or policies to enforce security restrictions can be much more convenient for users and can substantially enhance the user experience. In addition, mobile devices can be configured to communicate directly with the vehicle so that proximity status information can be determined between a general purpose mobile device and the vehicle without involving an intermediary such as a server and/or service provider .
    [0043] Examples may include an apparatus having a first factor module for determining a first proximity situation of a first mobile device to a vehicle and a second factor module for determining a second proximity situation of a second device mobile relative to the vehicle. The apparatus may also include a security module for configuring an accessibility of one or more vehicle functions based, at least in part, on the first proximity situation and the second proximity situation.
    [0044] Additionally, the security module can identify a policy associated with one or more of the first mobile device and the second mobile device, where accessibility must be additionally configured based on the policy.
    [0045] Additionally, the security module may receive a user request through a user interface from one or more of the first mobile device, the second mobile device and the vehicle, where accessibility must be configured in response to the user request.
    [0046] Furthermore, the security module can include a deny component to deny the user request if the first proximity situation and the second proximity situation do not satisfy a policy multifactor condition.
    [0047] Additionally, the security module can include a grant component to grant the user request if the first proximity situation and the second proximity situation satisfy a policy multifactor condition.
    [0048] Additionally, the granting component may apply one or more of a policy time constraint, a policy location constraint, and a policy login constraint to at least one of the vehicle's one or more functions.
    [0049] Furthermore, the security module may include a notification component to generate a notification through a user interface of one or more of the first mobile device, the second mobile device and the vehicle if the first situation of proximity indicates that the first mobile device is not present, or the second proximity situation indicates that the second mobile device is not present.
    [0050] Additionally, at least one of the one or more functions of the vehicle may include one or more of a door unlocking function, a trunk unlocking function, an ignition function, a user adjustment function, a vehicle operation function and a replacement device pairing function.
    [0051] Additionally, any of the aforementioned apparatus examples may additionally include a proximity sensor, wherein the first factor module must use the proximity sensor to determine the first proximity situation and the second factor module must use the sensor to determine the second proximity situation.
    [0052] The examples may also include a method in which a first proximity situation of a first mobile device is determined with respect to a vehicle. The method can also establish to determine a second proximity situation of a second mobile device in relation to the vehicle and configure an accessibility of one or more functions of the vehicle based at least in part on the first proximity situation and the second proximity situation.
    [0053] Additionally, the method may further include identifying a policy associated with one or more of the first mobile device and the second mobile device, wherein reachability is further configured based on the policy.
    [0054] Additionally, the method ■ may additionally include receiving a user request via a user interface from one or more of the first mobile device, the second mobile device and the vehicle, wherein accessibility is configured in response to the user request.
    [0055] Furthermore, the accessibility configuration can include denying the user request if the first proximity situation and the second proximity situation do not satisfy a multifactor condition of the policy.
    [0056] Additionally, the accessibility configuration can include granting the user request if the first proximity situation and the second proximity situation satisfy a policy multifactor condition.
    [0057] Additionally, the accessibility configuration may further include applying one or more of a policy time restriction, a policy location restriction, and a policy login restriction for at least one of the one or more functions of the vehicle.
    [0058] Furthermore, the accessibility configuration may include generating a notification through a user interface of one or more of the first mobile device, the second mobile device and the vehicle if the first proximity situation indicates that the first mobile device is not present or the second proximity situation indicates that the second mobile device is not present.
    [0059] Additionally, in any of the aforementioned method examples, at least one of the one or more vehicle functions may include one or more of a door unlocking function, a trunk unlocking function, an ignition function , a user adjustment function, a vehicle operation function and a replacement device pairing function.
    [0060] The examples may also include at least one machine-readable storage medium that has a set of instructions that, when executed by a processor, cause a vehicle to perform any of the aforementioned method examples.
    [0061] Furthermore, the examples may include a system having a proximity sensor and a first factor module for using the proximity sensor to determine a first proximity situation of a first mobile device with respect to a vehicle. The system may also have a second factor module to use the proximity sensor to determine a second proximity status of a second mobile device to the vehicle and a security module to configure an accessibility of one or more vehicle functions based on , at least in part, in the first situation of proximity and in the second situation of proximity.
    [0062] Examples may also include a mobile device that has a policy repository to store a policy with a multifactor condition. The mobile device may also include a wireless interface to receive a request from a vehicle security module and transmit the policy to the security module in response to the request.
    [0063] Additionally, the multifactor condition may indicate whether one or more functions should be accessible if the first mobile device or a second mobile device are not in proximity to the vehicle.
    [0064] Additionally, the mobile device may additionally include a pairing module for pairing the first mobile device with the vehicle.
    [0065] Furthermore, the pairing module can receive an access code through a user interface of the first mobile device, whereby the first mobile device must be paired with the vehicle only if the access code satisfies a restriction policy login page.
    [0066] Additionally, the wireless interface can receive a notification that the first mobile device is a master device, where the policy should include a plurality of user profiles.
    [0067] Additionally, the wireless interface of any of the aforementioned mobile device examples may receive a notification that the first mobile device or the second mobile device is not in proximity to the vehicle during an attempt to access one or more functions of the vehicle.
    [0068] The examples may also include at least one machine-readable storage medium comprising a set of instructions that, when executed by a processor, cause a first mobile device to perform methods of any of the aforementioned mobile device examples.
    [0069] Several modalities can be implemented with the use of hardware elements, software elements or a combination of both. Examples of hardware elements may include processors, microprocessors, circuits, circuit elements (eg transistors, resistors, capacitors, inductors, and so on), integrated circuits, application-specific integrated circuits (ASIC), programmable logic devices ( PLD), digital signal processors (DSP), field programmable gate arrays (FPGAs), logic gates, registers, semiconductor devices, boards, microboards, board assemblies, and so on. Examples of software may include software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions , methods, procedures, software interfaces, application program interfaces (API), instruction sets, computer code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof . Determining whether a modality is implemented using hardware elements and/or software elements can vary according to any number of factors such as desired computational rate, power levels, heat tolerances, processing cycle budget, rates of input data, output data rates, memory resources, data bus speeds, and other design or performance constraints.
    [0070] One or more aspects of at least one modality can be implemented by representative instructions stored on a machine-readable medium that represents various logics in the processor, which, when read by a machine, cause the machine to manufacture logic to perform the techniques described in this document. Such representations known as "IP cores" can be stored on a machine-readable, tangible medium and provided to various customers or manufacturing facilities to upload to the manufacturing machines that actually make the logic or processor.
    [0071] The embodiments of the present invention are applicable for use with all types of semiconductor integrated circuit ("IC") boards. Examples of these IC cards include, but are not limited to, processors, controllers, board assembly components, programmable logic arrays (PLAs), memory cards, network cards, and the like. Additionally, in some of the drawings, the signal conductor lines are represented by lines. Some may be different, to indicate more constituent signal paths, have a label amount, to indicate a number of constituent signal paths, and/or have arrows at one or more ends, to indicate the primary information flow direction. This, however, should not be interpreted in a limiting way. Rather, such added detail can be used in connection with one or more exemplary modalities to facilitate easier understanding of a circuit. Any signal lines represented, regardless of whether they have additional information or not, may in fact comprise one or more signals that can travel in different directions and may be deployed with any suitable type of signal scheme, for example, digital or analog lines deployed with differential pairs, fiber optic lines and/or single-ended lines.
    [0072] Exemplary sizes / models / values / ranges may be given, although the embodiments of the present invention are not limited thereto. As fabrication techniques (eg, photolithography) mature over time, it is expected that smaller-sized devices can be manufactured. Additionally, known power/ground connections with IC boards and other components may or may not be shown in the Figures, for the sake of simplicity of illustration and discussion and in order not to obscure certain aspects of embodiments of the invention. Furthermore, the arrangements may be shown in block diagram form in order to avoid obscuring the embodiments of the invention and also in view of the fact that specifications regarding the implementation of such block diagram arrangements are highly platform dependent on that the modality must be implemented, that is, such specifications must be well within the reach of a person skilled in the art. Where specific details (eg circuitry) are set forth in order to describe exemplary embodiments of the invention, it should be apparent to one of skill in the art that embodiments of the invention can be practiced without or with variation from these specific details. The description should then be considered illustrative rather than limiting.
    [0073] Some modalities can be implemented, for example, through the use of a machine or tangible computer-readable medium or article that can store an instruction or a set of instructions that, if executed by a machine, can cause the machine perform a method and/or operations according to the modalities. Such machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor or the like and may be deployed through the use of any suitable combination. hardware and/or software. The machine readable medium or article may include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium and/or storage unit , for example, memory, removable or non-removable media, erasable or non-erasable media, recordable or non-recordable media, digital or analog media, hard disk, floppy disk, Compact Disk with Read-Only Memory (CD-ROM), Compact Disk Recordable (CD-R), Compact Disc Rewritable (CD-RW), optical disc, magnetic media, magneto-optical media, removable memory cards or discs, various types of Digital Versatile Disc (DVD), a tape, a cassette or similar. Instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code and the like, deployed using any high-level, low-level programming language, object-oriented, visual, compiled and/or properly interpreted.
    [0074] Unless specifically stated otherwise, it may be noted that terms such as "processing", "computation", "calculation", "determination" or the like, refer to the action and/or processes of a computer or computing system or similar electronic computing device, which manipulates and/or transforms data represented as physical quantities (eg, electronic) in the records and/or memories of the computing system into other data similarly represented as physical quantities in the memories, records or other such information storage, transmission or display devices of the computer system. The modalities are not limited in this context.
    [0075] The term "coupled" may be used in this document to refer to any type of relationship, direct or indirect, between the components in question and may apply to electrical, mechanical, fluid, optical, electromagnetic connections, electromechanical or other connections. Additionally, the terms "first", "second", etc. they may be used in this document only to facilitate discussion and do not carry particular temporal or chronological significance, unless otherwise indicated.
    [0076] Those skilled in the art will note from the foregoing description that the broad techniques of embodiments of the present invention can be deployed in a variety of ways. Therefore, although the embodiments of this invention have been described in connection with particular examples thereof, the true scope of the embodiments of the invention should not be limited thereby, as other modifications will become evident to the practitioner versed in a study of the drawings. , descriptive report and claims to follow.
    权利要求:
    Claims (13)
    [0001]
    1. At least one machine-readable storage medium comprising a set of instructions characterized in that, when executed by a processor, causes a first mobile device (16): to store a policy that includes a multifactor condition that must include a number uniquely configured for a user stating how many devices (16, 18) should be required to allow a function of a vehicle to be accessible to the user; receive a request from a security module (24c) of a vehicle (1) ; and transmit the policy to the security module (24c) in response to the request.
    [0002]
    2. Method characterized by comprising: determining a first situation of proximity of a first mobile device (16) with respect to a vehicle; determining a second situation of proximity of a second mobile device (18) with respect to the vehicle (1); a policy associated with one or more of the first mobile device (16) and the second mobile device; and configure an accessibility of one or more vehicle functions (1) based at least in part on the first proximity situation and the second proximity situation, where the accessibility must be additionally configured based on the policy, where the policy must include a number uniquely configured for a user stating how many devices (16, 18) must be required to allow a function of a vehicle (1) to be accessible to the user.
    [0003]
    3. Method according to claim 2, characterized in that it further includes receiving a user request through a user interface from one or more of the first mobile device, the second mobile device and the vehicle, where accessibility is configured in response to the user's request.
    [0004]
    4. Method, according to claim 3, characterized in that configuring accessibility includes denying the user request if the first proximity situation and the second proximity situation do not satisfy a policy multifactor condition.
    [0005]
    5. Method, according to claim 3, characterized in that configuring accessibility includes granting the user request if the first proximity situation and the second proximity situation satisfy a policy multifactor condition.
    [0006]
    6. Method according to claim 5, characterized in that configuring accessibility additionally includes applying one or more of a policy time restriction, a policy location restriction, and a policy login restriction for by minus one of the vehicle's one or more functions.
    [0007]
    7. Method according to any one of claims 2 to 6, characterized in that configuring accessibility includes generating a notification through a user interface of one or more of the first mobile device, the second mobile device and the vehicle if the first proximity situation indicates that the first mobile device is not present or the second proximity situation indicates that the second mobile device is not present.
    [0008]
    8. Method according to any one of claims 2 to 6, characterized in that at least one of the one or more functions of the vehicle includes one or more of a door unlocking function, a door unlocking function. suitcases, an ignition function, a user adjustment function, a vehicle operation function, and a replacement device pairing function.
    [0009]
    9. At least one machine-readable storage medium comprising a set of instructions characterized in that, when executed by a processor, cause a vehicle to: determine a first proximity situation of a first mobile device (16) with respect to the vehicle; determines a second proximity situation of a second mobile device (18) with respect to the vehicle; identify a policy associated with one or more of the first mobile device (16) and the second mobile device (18); econfigure an accessibility of one or more vehicle functions based, at least in part, on the first proximity situation and the second proximity situation, where the accessibility must be additionally configured based on the policy, where the policy must include a uniquely configured number for a user stating how many devices (16, 18) should be required to allow a function of a vehicle (1) to be accessible to the user.
    [0010]
    10. Storage medium according to claim 9, characterized in that the instructions, when executed, cause the vehicle to: receive a user request through a user interface of one or more of the first device mobile, the second mobile device and the vehicle, where accessibility must be configured in response to the user request; deny the user request if the first proximity situation and the second proximity situation do not satisfy a multifactor condition of the policy; Grant the user request if the first proximity situation and the second proximity situation satisfy a policy multifactor condition.
    [0011]
    11. Storage medium according to claim 9, characterized in that the instructions, when executed, cause the vehicle to apply one or more of a policy time restriction, a policy location restriction and a restriction policy login settings for at least one of the vehicle's one or more functions.
    [0012]
    12. Storage medium according to any one of claims 9 to 11, characterized in that the instructions, when executed, cause the vehicle to generate a notification through a user interface of one or more of the first mobile device, the second mobile device and the vehicle if the first proximity situation indicates that the first mobile device is not present or the second proximity situation indicates that the second mobile device is not present, wherein at least one of the one or more Vehicle functions include one or more of a door unlock function, a trunk unlock function, an ignition function, a user adjustment function, a vehicle operation function, and a vehicle device pairing function. replacement.
    [0013]
    13. Apparatus (2) characterized in that it comprises: a first factor module (24a) for determining a first proximity situation of a first mobile device with respect to a vehicle; a second factor module (24b) for determining a second proximity situation of a second mobile device with respect to the vehicle; and a security module (24c) for configuring an accessibility of one or more functions of the vehicle based, at least in part, on the first proximity situation and the second proximity situation, the security module must additionally identify a policy associated with a or more between the first mobile device and the second mobile device, where accessibility must be additionally configured based on the policy, where the policy must include a number that is uniquely configured for a user stating how many devices (16, 18) should be required to allow a vehicle function to be accessible to the user.
    类似技术:
    公开号 | 公开日 | 专利标题
    BR112015004588B1|2021-06-01|MOBILE DEVICE AND MAGNETIC SENSOR KEY PAIRING FOR MULTIFACTOR SAFETY
    US9578037B2|2017-02-21|Allowing varied device access based on different levels of unlocking mechanisms
    JP2020005310A|2020-01-09|Method of authorizing operation to be performed on targeted computing device
    JP6861292B2|2021-04-21|System access using mobile devices
    TWI687835B|2020-03-11|An apparatus, a computer readable medium, and a system for pairing computing devices according to a multi-level security protocol
    KR20130133028A|2013-12-05|Method and device for managing digital usage rights of documents
    JP2015528668A|2015-09-28|Pluggable authentication mechanism for mobile device applications
    WO2013048439A1|2013-04-04|Managing basic input/output system | access
    US20150244717A1|2015-08-27|Trusted virtual computing system
    US11218478B1|2022-01-04|Security platform
    US20150381610A1|2015-12-31|Location-based data security
    EP2901761B1|2019-05-08|Providing limited access to a service device via an intermediary
    EP2947593B1|2019-10-09|Security apparatus session sharing
    US20160042161A1|2016-02-11|Providing access control of applications on computing device by establishing screen passcodes that allow access to designated screens with designated applications
    US10993100B2|2021-04-27|System and method of low energy mobile device recognition
    WO2021216030A1|2021-10-28|Remote connection decryption
    WO2021138626A1|2021-07-08|Autonomously generated portable accounts
    同族专利:
    公开号 | 公开日
    EP2900533A4|2016-08-03|
    CN104583044A|2015-04-29|
    US8933778B2|2015-01-13|
    JP2015529168A|2015-10-05|
    KR101690771B1|2016-12-29|
    KR20150036705A|2015-04-07|
    US20150109099A1|2015-04-23|
    WO2014052059A1|2014-04-03|
    BR112015004588A2|2017-07-04|
    JP2017024715A|2017-02-02|
    EP2900533A1|2015-08-05|
    EP2900533B1|2019-03-06|
    KR20170015934A|2017-02-10|
    JP6001176B2|2016-10-05|
    KR101955228B1|2019-03-08|
    US20140091903A1|2014-04-03|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US6225890B1|1998-03-20|2001-05-01|Trimble Navigation Limited|Vehicle use control|
    DE10015644A1|2000-03-29|2001-10-11|Bosch Gmbh Robert|Device for data exchange with a motor vehicle|
    US20010038328A1|2000-04-04|2001-11-08|King Ronald O.|Multifunction and multiple range RKE system and method|
    US20030163739A1|2002-02-28|2003-08-28|Armington John Phillip|Robust multi-factor authentication for secure application environments|
    JP4402338B2|2002-08-29|2010-01-20|株式会社東海理化電機製作所|Electronic key system|
    JP2004196154A|2002-12-19|2004-07-15|Sony Corp|Boarding environmental control system, boarding environmental control device, and boarding environmental control method|
    DE10307698A1|2003-02-21|2004-09-02|Robert Bosch Gmbh|Control device and computer program for controlling a drive unit of a vehicle|
    JP4460911B2|2004-02-16|2010-05-12|株式会社東海理化電機製作所|Security control system, security control device, portable device management device, and security control method|
    JP4547608B2|2004-05-21|2010-09-22|ソニー株式会社|Information storage control device, information management server, information storage control method, information management method, information storage control program, and information management program|
    US7031809B2|2004-05-21|2006-04-18|Jens Erik Sorensen|Remote control of automobile component arrangements|
    US9118656B2|2006-01-26|2015-08-25|Imprivata, Inc.|Systems and methods for multi-factor authentication|
    US9024721B2|2006-02-27|2015-05-05|Denso International America, Inc.|Apparatus for automatically changing state of vehicle closure|
    JP4535031B2|2006-06-30|2010-09-01|株式会社デンソー|In-vehicle device remote control system|
    US20080011827A1|2006-07-17|2008-01-17|Research In Motion Limited|Automatic management of security information for a security token access device with multiple connections|
    US7778751B2|2007-05-01|2010-08-17|Rti Technologies, Inc.|Method and apparatus for monitoring the status of automotive service equipment and signaling the status by a wireless technology to the operator|
    US20080312782A1|2007-06-15|2008-12-18|Gene Berdichevsky|Electric vehicle communication interface|
    US8044794B2|2008-08-07|2011-10-25|Harris Corporation|Mobile wireless communications device blocker and associated methods|
    US8825222B2|2009-02-27|2014-09-02|Toyota Motor Engineering & Manufacturing North America, Inc.|Remote management of vehicle settings|
    GB201008710D0|2010-05-25|2010-07-07|Jaguar Cars|Vehicle communications|
    US8847936B2|2010-07-02|2014-09-30|Deere & Company|Managing a display of a terminal device associated with a vehicle data bus|
    US8933778B2|2012-09-28|2015-01-13|Intel Corporation|Mobile device and key fob pairing for multi-factor security|US10404615B2|2012-02-14|2019-09-03|Airwatch, Llc|Controlling distribution of resources on a network|
    US9680763B2|2012-02-14|2017-06-13|Airwatch, Llc|Controlling distribution of resources in a network|
    US9306743B2|2012-08-30|2016-04-05|Texas Instruments Incorporated|One-way key fob and vehicle pairing verification, retention, and revocation|
    US8933778B2|2012-09-28|2015-01-13|Intel Corporation|Mobile device and key fob pairing for multi-factor security|
    US9247373B2|2013-03-01|2016-01-26|Denso International America, Inc.|Method of determining user intent to use services based on proximity|
    US9401915B2|2013-03-15|2016-07-26|Airwatch Llc|Secondary device as key for authorizing access to resources|
    US9132806B2|2013-06-27|2015-09-15|General Motors Llc|Remote start system for a motor vehicle|
    US10543808B2|2013-07-22|2020-01-28|Trw Automotive U.S. Llc|Passive remote keyless entry system with level-based anti-theft feature|
    US9213820B2|2013-09-10|2015-12-15|Ebay Inc.|Mobile authentication using a wearable device|
    US9373208B2|2013-09-11|2016-06-21|Sony Corporation|Secure remote control for operating closures such as garage doors|
    US9807172B2|2013-10-18|2017-10-31|At&T Intellectual Property I, L.P.|Mobile device intermediary for vehicle adaptation|
    US9499125B2|2013-10-29|2016-11-22|Volkswagen Aktiengesellschaft|Vehicle system for activating a vehicle component to provide vehicle access|
    US9203843B2|2013-11-08|2015-12-01|At&T Mobility Ii Llc|Mobile device enabled tiered data exchange via a vehicle|
    JP6079577B2|2013-11-18|2017-02-15|トヨタ自動車株式会社|Vehicle door control device|
    US9363264B2|2013-11-25|2016-06-07|At&T Intellectual Property I, L.P.|Networked device access control|
    CN105917586B|2013-12-31|2019-07-09|胡夫北美汽车零件制造股份有限公司|Bluetooth verifying for vehicle access system|
    US10251059B2|2014-01-21|2019-04-02|Everykey Inc.|Authentication device and method|
    US20150356797A1|2014-06-05|2015-12-10|International Business Machines Corporation|Virtual key fob with transferable user data profile|
    US9754431B2|2014-08-18|2017-09-05|Livio, Inc.|Method and system for a key fob base station enabling remote car access using a nomadic device|
    US9802574B2|2014-09-16|2017-10-31|Qualcomm Incorporated|Relay attack inhibiting|
    US9355551B2|2014-10-21|2016-05-31|Toyota Motor Engineering & Manufacturing North America, Inc.|Smart key locator|
    US10333980B2|2014-11-19|2019-06-25|Imprivata, Inc.|Personal device network for user identification and authentication|
    EP3064405B1|2015-03-05|2017-08-16|Betamotor S.p.A.|Double-security anti-theft emergency device for batteryless motor vehicles|
    EP3073283B1|2015-03-23|2019-04-24|Assa Abloy AB|Method and device for considering whether a portable key device is located inside or outside a barrier|
    KR102326710B1|2015-04-02|2021-11-17|소프트런치주식회사|System and method for authenticating based on context|
    DE102015206628B4|2015-04-14|2019-03-14|Volkswagen Aktiengesellschaft|Reference to authorized authentication media for a vehicle|
    EP3289792B1|2015-05-01|2020-06-24|Assa Abloy AB|Continuous authentication|
    JP2018521891A|2015-05-19|2018-08-09|ボヨモーティブ，エルエルシー|Stand-alone vehicle security method and apparatus|
    US9865110B2|2015-05-22|2018-01-09|M2MD Technologies, Inc.|Method and system for securely and automatically obtaining services from a machine device services server|
    US10308217B2|2015-06-16|2019-06-04|Ford Global Technologies, Llc|Method and apparatus for secure pairing|
    CN105216751B|2015-08-25|2018-04-10|四川长虹电器股份有限公司|Automobile system for unlocking and its method based on mobile network|
    EP3144902A1|2015-09-17|2017-03-22|Thomson Licensing|Docking station for synchronising vehicle system data in vehicle keys|
    FR3043964B1|2015-09-18|2019-05-31|Valeo Comfort And Driving Assistance|METHOD FOR CONTROLLING A FUNCTIONALITY OF A VEHICLE USING A USER TERMINAL AND CONTROL SYSTEM THEREFOR|
    DE112016005941T5|2016-01-19|2018-10-31|Ford Global Technologies, Llc|Systems and methods for user identification|
    DE102016203537A1|2016-03-03|2017-09-07|Volkswagen Aktiengesellschaft|Mobile user terminal, technical device and method for assisting a user in remote control of a technical device|
    JP2017193884A|2016-04-21|2017-10-26|株式会社東海理化電機製作所|Key security device|
    US10021029B2|2016-05-11|2018-07-10|International Business Machines Corporation|Method for routing incoming communication|
    KR20170138031A|2016-06-03|2017-12-14|자동차부품연구원|Authority sharing system of smart key and method of thereof|
    US10223852B2|2016-11-09|2019-03-05|Ford Global Technologies, Llc|Systems and methods for selective vehicle access|
    CN106585565A|2016-12-16|2017-04-26|江苏旭云物联信息科技有限公司|Intelligent automobile safety antitheft system|
    US9980020B1|2016-12-29|2018-05-22|Snap-On Incorporated|Remote locking system architecture and user interface|
    US10369988B2|2017-01-13|2019-08-06|Ford Global Technologies, Llc|Autonomous parking of vehicles inperpendicular parking spots|
    GB2560324B|2017-03-07|2019-08-07|Jaguar Land Rover Ltd|Apparatus and method for enabling storing of a user input vehicle setting|
    CN107089234B|2017-04-28|2019-12-13|北京新能源汽车股份有限公司|remote control driving control method and device, controller and automobile|
    US10683034B2|2017-06-06|2020-06-16|Ford Global Technologies, Llc|Vehicle remote parking systems and methods|
    US10585430B2|2017-06-16|2020-03-10|Ford Global Technologies, Llc|Remote park-assist authentication for vehicles|
    US10775781B2|2017-06-16|2020-09-15|Ford Global Technologies, Llc|Interface verification for vehicle remote park-assist|
    US10234868B2|2017-06-16|2019-03-19|Ford Global Technologies, Llc|Mobile device initiation of vehicle remote-parking|
    DE102017211321A1|2017-07-04|2019-01-10|Ford Global Technologies, Llc|Anti-theft device for a vehicle|
    JP6389938B2|2017-09-06|2018-09-12|キヤノン株式会社|Information processing apparatus and program|
    US11055802B2|2017-09-22|2021-07-06|Sensormatic Electronics, LLC|Methods and apparatus for implementing identity and asset sharing management|
    US10453319B2|2017-09-22|2019-10-22|Sensormatic Electronics, LLC|Methods and apparatus for management of intrusion detection systems using verified identity|
    US10829088B2|2017-09-22|2020-11-10|Sensormatic Electronics, LLC|Identity management for implementing vehicle access and operation management|
    DE102017122458A1|2017-09-27|2019-03-28|HELLA GmbH & Co. KGaA|System for a motor vehicle, method for controlling a motor vehicle component, computer program product and computer-readable medium|
    US10580304B2|2017-10-02|2020-03-03|Ford Global Technologies, Llc|Accelerometer-based external sound monitoring for voice controlled autonomous parking|
    US10281921B2|2017-10-02|2019-05-07|Ford Global Technologies, Llc|Autonomous parking of vehicles in perpendicular parking spots|
    EP3583754B1|2017-10-03|2020-12-02|Google LLC|Multi-factor authentication and access control in a vehicular environment|
    EP3471067A1|2017-10-11|2019-04-17|Continental Automotive GmbH|Security system and method|
    US10627811B2|2017-11-07|2020-04-21|Ford Global Technologies, Llc|Audio alerts for remote park-assist tethering|
    US10336320B2|2017-11-22|2019-07-02|Ford Global Technologies, Llc|Monitoring of communication for vehicle remote park-assist|
    US10578676B2|2017-11-28|2020-03-03|Ford Global Technologies, Llc|Vehicle monitoring of mobile device state-of-charge|
    US10585431B2|2018-01-02|2020-03-10|Ford Global Technologies, Llc|Mobile device tethering for a remote parking assist system of a vehicle|
    US10583830B2|2018-01-02|2020-03-10|Ford Global Technologies, Llc|Mobile device tethering for a remote parking assist system of a vehicle|
    US10974717B2|2018-01-02|2021-04-13|Ford Global Technologies, I.LC|Mobile device tethering for a remote parking assist system of a vehicle|
    US10688918B2|2018-01-02|2020-06-23|Ford Global Technologies, Llc|Mobile device tethering for a remote parking assist system of a vehicle|
    US11148661B2|2018-01-02|2021-10-19|Ford Global Technologies, Llc|Mobile device tethering for a remote parking assist system of a vehicle|
    US10737690B2|2018-01-02|2020-08-11|Ford Global Technologies, Llc|Mobile device tethering for a remote parking assist system of a vehicle|
    US10814864B2|2018-01-02|2020-10-27|Ford Global Technologies, Llc|Mobile device tethering for a remote parking assist system of a vehicle|
    US10684773B2|2018-01-03|2020-06-16|Ford Global Technologies, Llc|Mobile device interface for trailer backup-assist|
    US10747218B2|2018-01-12|2020-08-18|Ford Global Technologies, Llc|Mobile device tethering for remote parking assist|
    US10917748B2|2018-01-25|2021-02-09|Ford Global Technologies, Llc|Mobile device tethering for vehicle systems based on variable time-of-flight and dead reckoning|
    US10684627B2|2018-02-06|2020-06-16|Ford Global Technologies, Llc|Accelerometer-based external sound monitoring for position aware autonomous parking|
    US11188070B2|2018-02-19|2021-11-30|Ford Global Technologies, Llc|Mitigating key fob unavailability for remote parking assist systems|
    US10507868B2|2018-02-22|2019-12-17|Ford Global Technologies, Llc|Tire pressure monitoring for vehicle park-assist|
    US10732622B2|2018-04-05|2020-08-04|Ford Global Technologies, Llc|Advanced user interaction features for remote park assist|
    US10683004B2|2018-04-09|2020-06-16|Ford Global Technologies, Llc|Input signal management for vehicle park-assist|
    US10759417B2|2018-04-09|2020-09-01|Ford Global Technologies, Llc|Input signal management for vehicle park-assist|
    US10793144B2|2018-04-09|2020-10-06|Ford Global Technologies, Llc|Vehicle remote park-assist communication counters|
    US10493981B2|2018-04-09|2019-12-03|Ford Global Technologies, Llc|Input signal management for vehicle park-assist|
    US10232673B1|2018-06-01|2019-03-19|Ford Global Technologies, Llc|Tire pressure monitoring with vehicle park-assist|
    TWI672934B|2018-06-15|2019-09-21|宏碁股份有限公司|Security system of vehicle and operating method thereof|
    US10384605B1|2018-09-04|2019-08-20|Ford Global Technologies, Llc|Methods and apparatus to facilitate pedestrian detection during remote-controlled maneuvers|
    US10717432B2|2018-09-13|2020-07-21|Ford Global Technologies, Llc|Park-assist based on vehicle door open positions|
    US10821972B2|2018-09-13|2020-11-03|Ford Global Technologies, Llc|Vehicle remote parking assist systems and methods|
    US10967851B2|2018-09-24|2021-04-06|Ford Global Technologies, Llc|Vehicle system and method for setting variable virtual boundary|
    US10529233B1|2018-09-24|2020-01-07|Ford Global Technologies Llc|Vehicle and method for detecting a parking space via a drone|
    US10908603B2|2018-10-08|2021-02-02|Ford Global Technologies, Llc|Methods and apparatus to facilitate remote-controlled maneuvers|
    US10628687B1|2018-10-12|2020-04-21|Ford Global Technologies, Llc|Parking spot identification for vehicle park-assist|
    US11097723B2|2018-10-17|2021-08-24|Ford Global Technologies, Llc|User interfaces for vehicle remote park assist|
    US11137754B2|2018-10-24|2021-10-05|Ford Global Technologies, Llc|Intermittent delay mitigation for remote vehicle operation|
    KR20200109182A|2019-03-12|2020-09-22|두산인프라코어 주식회사|Control system and control method for construction machinery|
    US11195344B2|2019-03-15|2021-12-07|Ford Global Technologies, Llc|High phone BLE or CPU burden detection and notification|
    US11169517B2|2019-04-01|2021-11-09|Ford Global Technologies, Llc|Initiation of vehicle remote park-assist with key fob|
    US10832509B1|2019-05-24|2020-11-10|Ademco Inc.|Systems and methods of a doorbell device initiating a state change of an access control device and/or a control panel responsive to two-factor authentication|
    US10789800B1|2019-05-24|2020-09-29|Ademco Inc.|Systems and methods for authorizing transmission of commands and signals to an access control device or a control panel device|
    US11037388B2|2019-10-09|2021-06-15|Ford Global Technologies, Llc|Systems and methods for creating a password and/or a keypad code for executing keyless operations upon a vehicle|
    KR102327081B1|2020-04-10|2021-11-16|주식회사 휴머니컴|A Digital Smart Key System for a Vehicle and a Method for Managing the Vehicle with the Same|
    JP2021012719A|2020-10-07|2021-02-04|グーグル エルエルシーＧｏｏｇｌｅ ＬＬＣ|Multi-factor authentication and access control in vehicular environment|
    法律状态:
    2020-01-07| B06U| Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]|
    2021-04-13| B09A| Decision: intention to grant [chapter 9.1 patent gazette]|
    2021-06-01| B16A| Patent or certificate of addition of invention granted|Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 16/09/2013, OBSERVADAS AS CONDICOES LEGAIS. |
    优先权:
    申请号 | 申请日 | 专利标题
    US13/631,440|2012-09-28|
    US13/631,440|US8933778B2|2012-09-28|2012-09-28|Mobile device and key fob pairing for multi-factor security|
    PCT/US2013/059873|WO2014052059A1|2012-09-28|2013-09-16|Mobile device and key fob pairing for multi-factor security|
    [返回顶部]